Size Change: -12 B (0%)

Total Size: 1.2 MB

_{compressed-size-action}

I understand not wanting to show template/template-parts from OTHER themes, but why would we not want to show custom ones?

@Addison-Stavlo new ones are created with the current theme set in the wp_theme taxonomy:

new ones are created with the current theme set in the wp_theme taxonomy:

I see. So custom template parts are then tied to a theme, which may not be ideal for users wanting to create custom template parts to use across whatever theme they choose to have active. 🤔

@Addison-Stavlo I'm sure this has been discussed to death already, but I'm failing at finding where. 🤔

My reasoning here is that having templates and parts always tied to a theme (and never showing other theme's items in the Site Editor), massively simplifies all the flows.
We don't have to worry about what happens when changing theme, for example.

Regardless, as far as I can see, we now have all the pieces (post status, theme and _wp_file_based tags) to build the puzzle as we see fit, so I think we wouldn't have a hard time changing directions either way.

For example, I can imagine a scenario where we update the theme tag if a user updates a template while using a different theme than the template's one.
Or, instead of updating the theme tag, we could insert a new one, so that templates would belong to multiple themes.
We could have give users the control, by introducing a UI to manually change the theme tag(s).

I'm sure this has been discussed to death already, but I'm failing at finding where.

Im not sure if it has been actually, at least regarding whether custom created template parts should or shouldn't correspond to the theme that was active at the time of their creation. I think in the early stages of the site editor there wasn't much design involvement and a lot of the early development was going on a best guess of what we would need. The earliest stage I can remember regarding template part theme names behaved as: auto-drafts theme files get the theme name, wp-admin creation had the empty string, and in editor creation gave the user an empty input to put whatever they chose for the theme name. So coming in at that point I was assuming we had a need for having some separation between theme and custom and to not necessarily lump them together automatically under the same umbrella.

Given that the current state of the site editor best suits theme development, maybe this behavior isn't necessarily a bad thing for now. It does get fuzzy if we think of a user wanting to create a 'custom' type that is usable for their site regardless of any theme. 🤔 How much that makes sense in practice, I'm not sure 🤷‍♀️

For example, I can imagine a scenario where we update the theme tag if a user updates a template while using a different theme than the template's one.
We could have give users the control, by introducing a UI to manually change the theme tag(s).

But if we are only showing current theme in the site editor, they would have to navigate to wp-admin to do this? That fragments the experience quite a bit.

Anyways, with the way things are currently working I don't see any reason to block this PR. I do think we may need to rethink how/when we are adding the theme tag and that a _custom type may be necessary in the future.

I think the end goal of this PR corresponds to the state we are now currently in as a result of #27910 ?

Im not sure if you want to close this or if there are still other issues to work out.

Thanks for checking this @Addison-Stavlo, I'll close it as not relevant anymore.